Source access node, target access node and methods for enhanced handover

ABSTRACT

Embodiments herein relate to, e.g., a method performed by a source access node relating to handover of a UE. The source access node sends to a target access node, an initial handover preparation message with a first explicit indicator for the target access node to request an enhanced Make-Before-Break Handover. The source access node receives an handover preparation response message from the target access node, with a second explicit indicator accepting or rejecting the requested enhanced Make-Before-Break Handover. Further, the source access node selects a possible fallback mechanism, upon reception of the handover preparation response message from the target access node indicating rejection or no support of enhanced Make-Before-Break Handover.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation U.S. application Ser. No. 17/427,821,filed Aug. 2, 2021, which is a U.S. National Stage Patent Application ofInternational Application No.: PCT/SE2020/050156, filed Feb. 13, 2020entitled “SOURCE ACCESS NODE, TARGET ACCESS NODE AND METHODS FORENHANCED HANDOVER,” which claims priority to U.S. ProvisionalApplication No.: 62/805,466, filed Feb. 14, 2019, entitled “NETWORK NODEAND METHOD FOR ENHANCED HANDOVER,” the entireties of all of which areincorporated herein by reference.

TECHNICAL FIELD

Embodiments herein relate to a source access node, a target access node,and methods performed therein for wireless communication. Furthermore, acomputer program product and a computer readable storage medium are alsoprovided herein. In particular, embodiments herein relate to networksignalling for enhanced handover.

BACKGROUND

A Universal Mobile Telecommunications System (UMTS) is a thirdgeneration (3G) telecommunication network, which evolved from the secondgeneration (2G) Global System for Mobile Communications (GSM).Specifications for the Evolved Packet System (EPS), also called a FourthGeneration (4G) network or Long Term Evolution (LTE), have beencompleted within the 3rd Generation Partnership Project (3GPP) and thiswork continues in the coming 3GPP releases, for example to specify aFifth Generation (5G) New Radio (NR) network.

Consider a wireless communication system illustrated in FIG. 1 . Thewireless communication system may comprise one or more radio accessnetwork (RAN), where a radio access network 10, which may also bereferred to as a network node, is shown with a user equipment (UE) 12,which communicates with one or multiple access nodes 13-14, using radioconnections 17-18. The access nodes 13-14 are connected to a corenetwork (CN) node 16. The access nodes 13-14 are part of radio accessnetwork 10.

For wireless communication systems pursuant to 3GPP EPS or LTE or 4Gstandard specifications, such as specified in 3GPP TS 36.300 v.15.0.0and related specifications, the access nodes 13-14 corresponds typicallyto an Evolved NodeB (eNB) and the core network node 16 correspondstypically to either a Mobility Management Entity (MME) and/or a ServingGateway (SGW). The eNB is part of the radio access network 10, which inthis case is the Evolved Universal Terrestrial Radio Access Network(E-UTRAN), while the MME and SGW are both part of the Evolved PacketCore network (EPC).

For wireless communication systems pursuant to 3GPP 5G System (5GS) alsoreferred to 5G NR standard specifications, such as specified in 3GPP TS38.300 v 15.0.0 and related specifications, on the other hand, theaccess nodes 13-14 correspond typically to 5G NodeBs, denoted as gNBs,and the core network node 16 corresponds typically to either a Accessand Mobility Management Function (AMF) node and/or a User Plane Function(UPF) node. A gNB is part of the radio access network 10, which in thiscase is the Next Generation Radio Access Network (NG-RAN), while the AMFand UPF are both part of the 5G Core Network (5GC).

To support fast mobility between NR and LTE and avoid change of corenetwork, LTE access nodes, denoted as eNBs, may also be connected to the5G-CN via interfaces NG-U and/or NG-C and support the Xn interface. AneNB connected to 5GC is called a next generation eNB (ng-eNB) and isconsidered part of the NG-RAN. LTE connected to 5GC will not bediscussed further in this document; however, it should be noted thatmost of the solutions and features described for LTE and NR in thisdocument also apply to LTE connected to 5GC. In this document, when theterm LTE is used without further specification it refers to LTE-EPC.

Mobility in RRC_CONNECTED in LTE and NR.

Mobility in RRC_CONNECTED state is also known as handover. The purposeof a handover is to move the UE 12, due to e.g. mobility, from a sourceaccess node 13, using a source radio connection 17, to a target accessnode 14, using a target radio connection 18. The target radio connection18 is associated with a target cell controlled by the target access node14. So in other words, during a handover, the UE 12 moves from a sourcecell to the target cell.

In some cases, the source access node 13 and target access node 14 aredifferent nodes, such as different eNBs or gNBs. These cases arereferred to as inter-node handover, inter-eNB handover or inter-gNBhandover. In other cases, the source access node 13 and target accessnode 14 are the same node, such as the same eNB and gNB. These cases arereferred to as intra-node handover, intra-eNB handover or intra-gNBhandover and cover the case when source and target cells are controlledby the same radio access node. In yet other cases, handover is performedwithin the same cell, and thus also within the same access nodecontrolling that cell. These cases are referred to as intra-cellhandover.

It should therefore be understood that the source access node 13 andtarget access node 14 refers to a role served by a given access nodeduring a handover of a specific UE. For example, a given radio accessnode may serve as source access node during handover of one UE, while italso serves as the target access node during handover of a different UE.And, in case of an intra-node or intra-cell handover of a given UE, thesame radio access node serves both as the source access node and targetaccess node for that UE.

An RRC_CONNECTED UE in E-UTRAN or NG-RAN can be configured by thenetwork to perform measurements of serving and neighbor cells and basedon the measurement reports sent by the UE, the network may decide toperform a handover of the UE to a neighbor cell. The network then sendsa Handover Command message to the UE, for example, in LTE anRRCConnectionReconfiguration message with a field calledmobilityControlInformation and in NR an RRCReconfiguration message witha reconfigurationWithSync field.

These reconfigurations are actually prepared by the target access nodeupon a request from the source access node over X2 or S1 interface incase of EUTRA-EPC or Xn or NG interface in case of NG-RAN-5GC, and takesinto account the existing radio resource control (RRC) configuration theUE has with source access node, which are provided in the inter-noderequest. The reconfiguration parameters provided by the target accessnode contains, for example, information needed by the UE to access thetarget access node, e.g., random access configuration, a new Cell RadioNetwork Temporary Identifier (C-RNTI) assigned by the target access nodeand security parameters enabling the UE to calculate new security keysassociated to the target access node so the UE can send a HandoverComplete message on signalling radio bearer (SRB1), encrypted andintegrity protected, based on new security keys upon accessing thetarget access node.

FIG. 2 shows a signaling flow between UE, source access node 13, alsoknown as source gNB or source cell, and target access node 14, alsoknown as target gNB or target cell, during a handover procedure, using5G/NR as example.

Although the signaling flow in FIG. 2 shows a handover scenario in5G/NR, there are some general and common principles for UEs performinghandover or in more general terms, mobility in RRC_CONNECTED in LTE andNR:

Mobility in RRC_CONNECTED is Network-controlled as the network has bestinformation regarding current situation such as load conditions,resources in different nodes, available frequencies, etc. Network canalso take into account the impact from other UEs served by the network,e.g. from a resource allocation perspective.

Network prepares a target cell controlled by a target access node 14before the UE accesses that access node. Source access node 13 providesthe UE with the RRC configuration to be used in the target cell,including signalling radio bearer 1 (SRB1) configuration to be used bythe UE when sending the handover (HO) Complete message in the targetcell.

The UE is provided by the target access node with a new C-RNTI. The UE12 identifies itself by conveying the C-RNTI in message 3 (MSG3) in theHO Complete message. Hence, there is no context fetching between targetaccess node and source access node, unless a failure occurs.

To speed up the handover, network provides the UE 12 with informationhow to access the target access node e.g. random access channel (RACH)configuration, so the UE 12 does not have to acquire system information(SI) prior to the handover.

UE may be provided with contention-free random access (CFRA) resources,i.e. in that case the target access node 14 identifies the UE from thepreamble in MSG1. The principle is that the handover procedure canalways be optimized with network pre-allocated resources.

Security is prepared before the UE accesses the target cell controlledby the target access node i.e. keys must be refreshed before sending theencrypted and integrity protected HO Complete message, in LTE the RRCConnection Reconfiguration Complete message, so that the UE can beverified by the target access node.

Both full and delta reconfiguration are supported so that the HO commandcan be minimized.

Make-Before-Break Rel-14:

Handover interruption time is typically defined as the time from the UE12 stops transmission and/or reception with the source access node 13(such as a eNB or gNB) until the target access node 14 (such as a eNB orgNB) resumes transmission/reception with the UE 12.

In LTE pre-Rel-14, according to 3GPP TR 36.881 v 14.0.0, the handoverinterruption time is at least 45 ms. In LTE and NR, different solutionsto decrease the handover interruption time have since then beendiscussed. Improvements are driven for example by new servicerequirements on low latency e.g. aerial, industrial automation,industrial control, for which low interruption time shall be guaranteed.

As an example of one such improvement, Make-Before-Break (MBB) wasintroduced in LTE Rel-14 in purpose to shorten handover interruptiontime as close to Oms as possible. FIG. 3 shows signaling forMake-before-break in LTE Rel-14.

The MBB handover procedure as introduced in LTE Rel-14, refers to ahandover mechanism where the UE connects to the target cell beforedisconnecting from the source cell unlike the standard handoverprocedure where the UE resets media access control (MAC) andre-establishes Packet Data Convergence Protocol (PDCP) upon receivingthe HO Command message, RRCConnectionReconfiguration message withmobilityControlInfo, in the source cell. The mobilityControlInfo in theRRCConnectionReconfiguration message includes an information element(IE) makeBeforeBreak, to instruct the UE to keep the connection to thesource cell. From 3GPP TS 36.331 v.15.0.0:

makeBeforeBreak (MBB) Information Element (IE)

This information element indicates that the UE shall continue uplinktransmission and/or downlink reception with the source cell(s) beforeperforming the first transmission through physical random access channel(PRACH) to the target intra-frequency primary cell (PCell), orperforming initial physical uplink shared channel (PUSCH) transmissionto the target intra-frequency PCell while rach-Skip is configured.

NOTE 1a: It is up to UE implementation when to stop the uplinktransmission and/or downlink reception with the source cell(s) toinitiate re-tuning for connection to the target cell, as specified in TS36.133 v16.0.0, if makeBeforeBreak is configured.

In the MBB solution, the connection to the source cell is maintainedafter the reception of RRCConnectionReconfiguration message, with themakeBeforeBreak IE present in the mobilityControlInfo, until the UEexecutes initial uplink transmission in the target cell, i.e. MAC andPDCP reset is delayed in the UE until the UE performs random-access inthe target cell. It is up to UE implementation when to stop the uplinktransmission/downlink reception with the source cell to initiatere-tuning for connection to the target cell.

MBB as specified in LTE Rel-14 v.14.0.0 (3GPP TS 36.300 and TS 36.331)has some known limitations: Even if MBB and other improvements, such asRACH-less handover are combined it is still not possible to reach ˜0 mshandover interruption time. MBB in Rel-14 is designed for UEs withsingle transmit and receive (Tx/Rx) chain which means that MBB inpractice only supports intra-frequency handover. In an intra-frequencyhandover scenario, a single Rx UE is capable of receiving DL data fromboth target and source cell, however, a single Tx UE will not be able totransmit to both cells simultaneously. Thus, in MBB Rel-14, the UE willrelease the connection to the source cell at the first UL transmission.This occurs when the UE transmits the RACH preamble; or transmits the HOComplete message, if RACH-less HO is configured.

Consequently, the UE releases the connection with the source cell beforethe connection with the target cell is ready for packet transmissionand/or reception.

Enhanced Make-Before-Break.

Two new work items for mobility enhancements in LTE and NR have startedin 3GPP in release 16. The main objectives of the work items are toimprove the robustness at handover and to further decrease theinterruption time at handover.

Improvements to the LTE Rel-14 make-before-break handover have beenproposed in the past. Some of these improvements would benefit from UEswith dual Tx/Rx radio chain, such a UE has dual radio transmitters andreceivers and associated dual user plane protocol stacks. One example ofsuch proposed improvement for LTE Rel-16 is shown in FIG. 4 .

The key steps to support Oms HO interruption time by means of EnhancedMBB procedure are as follows:

-   -   Step 4: Source eNB sends Handover Command i.e.        RCConnectionReconfiguration message with mobilityControlInfo to        the UE, containing an indicator e.g. enhanced MBB indicator to        perform Oms HO interruption.    -   Step 5: Source eNB starts forwarding DL PDCP packets to the        target eNB and continues to send and receive PDCP packets        to/from the UE (step 7). DL PDCP packets forwarded from source        eNB are buffered in the target eNB.    -   Step 6: UE starts synchronizing with the target cell, while        keeping its connection with the source cell.    -   Step 7: Packet data is still sent and received via the source        cell.    -   Step 8: UE performs random-access in the target cell and target        eNB schedules uplink resources.    -   Step 9: UE sends RRCConnectionReconfigurationComplete message in        the target cell. The target eNB can now start sending PDCP        packets to the UE, while at the same time, the source eNB may        continue to send PDCP packets to the UE. From this point in time        the UE only sends UL data via the target cell. In purpose to        assist the target eNB with PDCP duplication check, the UE may        convey a PDCP Status Report in the        RRCConnectionReconfigurationComplete message. Based on the        information in the PDCP Status Report, the target eNB will only        send PDCP packets to the UE that were not received by the UE in        the source cell.    -   Step 10: The UE distinguishes PDCP packets received from source        and target cell.    -   Step 11: Source eNB sends an sequence number (SN) Status        Transfer message to the target eNB when the        transmission/reception to/from the UE has ended, indicating the        uplink/downlink PDCP SN receiver/transmitter status.    -   Step 12: UE detaches from source cell when the connection        procedure to the target cell is completed.    -   Step 13: Target eNB informs source eNB to release UE Context.

3GPP discussions to decrease the handover interruption time based one.g. the enhanced make-before-break for LTE, including additionalactions needed from the target access node, are currently ongoing forLTE and NR.

Inter-Node Messages for Mobility. RRC Inter-Node Messages.

During mobility, such as handover, from a source access node to a targetaccess node, such as a source gNB to a target gNB, or a source eNB to atarget eNB, in NR and LTE, two inter-node messages are typically used:HandoverPreparationInformation and HandoverCommand. When the sourceaccess node decides to handover the UE, the source access node providesthe target access node with some information in theHandoverPreparationInformation that enables the target access node toprepare an RRCReconfiguration, provided in the HandoverCommand, to beused by the UE when accessing the target cell upon handover execution.Definitions from TS 38.331 v.15.0.0 are shown below:

HandoverPreparationInformation.

This message is used to transfer the NR RRC information used by thetarget gNB during handover preparation, including UE capabilityinformation.

Direction: source gNB/source RAN to target gNB.

HandoverPreparationInformation message -- ASN1START --TAG-HANDOVER-PREPARATION-INFORMATION-STARTHandoverPreparationInformation ::= SEQUENCE { criticalExtensions CHOICE{ c1 CHOICE { handoverPreparationInformationHandoverPreparationInformation-IEs, spare3 NULL, spare2 NULL, spare1NULL }, criticalExtensionsFuture SEQUENCE { } } }HandoverPreparationInformation-IEs ::= SEQUENCE { ue-CapabilityRAT-ListUE-CapabilityRAT-ContainerList, sourceConfig AS-Config OPTIONAL, -- CondHO rrm-Config RRM-Config OPTIONAL, as-Context AS-Context OPTIONAL,nonCriticalExtension SEQUENCE { } OPTIONAL } AS-Config ::= SEQUENCE {rrcReconfiguration OCTET STRING (CONTAINING RRCReconfiguration), ... }AS-Context ::= SEQUENCE { reestablishmentInfo ReestablishmentInfoOPTIONAL, configRestrictInfo ConfigRestrictInfoSCG OPTIONAL, ..., [[ran-NotificationAreaInfo RAN-NotificationAreaInfo OPTIONAL ]] }ReestablishmentInfo ::= SEQUENCE { sourcePhysCellId PhysCellId,targetCellShortMAC-I ShortMAC-I, additionalReestabInfoListReestabNCellInfoList OPTIONAL } ReestabNCellInfoList ::= SEQUENCE ( SIZE(1..maxCellPrep) ) OF ReestabNCellInfo ReestabNCellInfo::= SEQUENCE{cellIdentity CellIdentity, key-gNodeB-Star BIT STRING (SIZE (256)),shortMAC-I ShortMAC-I } RRM-Config ::= SEQUENCE { ue-InactiveTimeENUMERATED { s1, s2, s3, s5, s7, s10, s15, s20, s25, s30, s40, s50,min1, min1s20c, min1s40, min2, min2s30, min3, min3s30, min4, min5, min6,min7, min8, min9, min10, min12, min14, min17, min20, min24, min28,min33, min38, min44, min50, hr1, hr1min30, hr2, hr2min30, hr3, hr3min30,hr4, hr5, hr6, hr8, hr10, hr13, hr16, hr20, day1, day1hr12, day2,day2hr12, day3, day4, day5, day7, day10, day14, day19, day24, day30,dayMoreThan30} OPTIONAL, candidateCellInfoList MeasResultList2NROPTIONAL, ... } -- TAG-HANDOVER-PREPARATION-INFORMATION-STOP -- ASN1STOP

HandoverPreparationInformation field descriptions as-Context Local RANcontext required by the target gNB. sourceConfig The radio resourceconfiguration as used in the source cell. rrm-Config Local RAN contextused mainly for RRM purposes. ue-CapabilityRAT-List The UE radio accessrelated capabilities concerning RATs supported by the UE. FFS whethercertain capabilities are mandatory to provide by source e.g. of targetand/or source RAT.

Conditional Presence Explanation HO The field is mandatory present incase of handover within NR; The field is optionally present in case ofhandover from E-UTRA connected to 5GC; otherwise the field is notpresent.

NOTE 2: The following table indicates per source RAT whether RATcapabilities are included or not.

Source RAT NR capabilities E-UTRA capabilities MR-DC capabilities NRIncluded May be included May be included E-UTRAN Included May beincluded May be included

RRM-Config field descriptions candidateCellInfoList A list of the bestcells on each frequency for which measurement information was available

HandoverCommand

This message is used to transfer the handover command as generated bythe target gNB.

Direction: target gNB to source gNB/source RAN.

HandoverCommand message -- ASN1START -- TAG-HANDOVER-COMMAND-STARTHandoverCommand ::= SEQUENCE { criticalExtensions CHOICE { c1 CHOICE {handoverCommand HandoverCommand-IEs, spare3 NULL, spare2 NULL, spare1NULL }, criticalExtensionsFuture SEQUENCE { } } } HandoverCommand-IEs::= SEQUENCE { handoverCommandMessage OCTET STRING (CONTAININGRRCReconfiguration), nonCriticalExtension SEQUENCE { } OPTIONAL } --TAG-HANDOVER-COMMAND-STOP -- ASN1STOP

Xn inter-node messages for handover/DC-setup.

According to TS 38.420 v.15.2.0, there is a function called “Handoverpreparation function” defined as follows:

Handover Preparation Function

This function allows the exchange of information between source andtarget NG-RAN nodes in order to initiate the handover of a certain UE tothe target.

Another function that is relevant is the “Handover cancelling function”defined as follows:

Handover Cancellation Function

This function allows informing an already prepared target NG-RAN nodethat a prepared handover will not take place. It allows releasing theresources allocated during a handover preparation function.

In TS 38.423 v.15.2.0 these functions are described in more details, seesections 8.2.1 and 8.2.3.

The existing solution, i.e. for release-14 Make-Before-Break, does notimply special actions from the target access node, compared to legacyhandover. In enhanced Make-Before-Break the target access node needs tounderstand that the source access node is requesting an enhancedMake-Before-Break handover in order to take a decision, i.e. reject oraccept, and start the required actions, which in some cases aredifferent for enhanced Make-before-break compared to other types ofhandover, such as Rel-14 Make-before-break. An example of such an actionis the transmission of SN Status Transfer from the source access node.Also, in some cases, such as in case of different vendors, or differentsoftware versions, the target access node does not support enhancedMake-before-break, even if the source access node does.

SUMMARY

As part of developing embodiments herein the following has beenidentified. The source access node does not signal the desired fallbackmechanism to be used in case the target access node rejects the enhancedMake-Before-Break request. This may result in additional delay for theUE to be handed over to a new node, i.e. the source node may need tostart a new Handover procedure towards the same or another target node.

If the target access node rejects the enhanced Make-Before-Breakrequest, it cannot choose a handover fallback mechanism, e.g. to alegacy handover, which could avoid additional delay for the UE to behanded over to a new node.

If the target access node does not support enhanced Make-Before-Break,the source access node may not know it, and therefore it may start tosend DL packets to an already detached UE. For the source access node toknow whether the target access node supports enhanced MBB or not, thesource access node need to read the content of the MobilityControlInfoincluded in the transparent container, e.g. included in the HANDOVERREQUEST ACKNOWLEDGE message, prepared by the target access node.

If the target access node rejects or does not support enhancedMake-Before-Break, the source access node needs to start a new HandoverPreparation, which results in additional delay for the UE to be handedover to a new node.

If the target access node rejects or does not support enhancedMake-Before-Break (eMBB), the source access node may not make thedifference between the two, i.e. eMBB not supported or eMBB temporaryrejected, and therefore could continue sending requests to a node notsupporting this feature. In order to avoid this behavior, the sourceaccess node needs to be configured with all the possible target accessnodes capabilities.

It is therefore an object of embodiments herein to provide an improvedmethod for handling handover of a UE.

According to embodiments herein, the object may be achieved by providinga method performed by a source access node relating to handover of a UE.The source access node sends to a target access node, an initialhandover preparation message with a first explicit indicator for thetarget access node to request an enhanced Make-Before-Break Handover.The source access node receives an handover preparation response messagefrom the target access node, with a second explicit indicator acceptingor rejecting the requested enhanced Make-Before-Break Handover. Further,the source access node selects a possible fallback mechanism, uponreception of the handover preparation response message from the targetaccess node indicating rejection or no support of enhancedMake-Before-Break Handover. E.g. it is herein disclosed a methodperformed in the source access node taking a decision to perform anenhanced Make-Before-Break Handover for a UE, preparing a target accessnode, and acting upon a response message from the target access node,the method may comprise: sending an initial Handover Preparation messagewith an explicit indicator for the target access node to request anenhanced Make-Before-Break Handover; notifying the target access node ofthe desired fallback in case of failure or reject of the enhancedMake-Before-Break Handover request; receiving and processing an HandoverPreparation response message from the target access node, with anexplicit indicator accepting or rejecting the enhanced Make-Before-BreakHandover request; learning the target enhanced Make-Before-Breakcapability from the target response message to the enhancedMake-Before-Break Handover request; and selecting a possible fallbackmechanism, i.e. handover alternative, upon reception of the targetaccess node rejecting or not supporting enhanced Make-Before-BreakHandover.

According to embodiments herein, the object may be achieved by providinga method performed by a target access node relating to handover of a UE,from a source access node to the target access node. The target accessnode receives an initial handover preparation message with a firstexplicit indicator from the source access node requesting an enhancedMake-Before-Break Handover; and responds to the initial handoverpreparation message sent by the source access node, with a handoverpreparation response message with a second explicit indicator acceptingor rejecting the enhanced Make-Before-Break Handover request. E.g. thetarget access node may perform a method taking a decision to accept orreject an enhanced Make-Before-Break Handover request for a UE andinforming the source access node. The method may comprise: receiving andprocessing an initial Handover Preparation message with an explicitindicator from the source access node requesting an enhancedMake-Before-Break Handover; responding to an initial HandoverPreparation message sent by the source access node, with an explicitindicator accepting or rejecting the enhanced Make-Before-Break Handoverrequest; selecting a possible fallback mechanism in case of rejection ofthe enhanced Make-Before-Break Handover; notifying the source accessnode of the desired fallback mechanism in case of rejection of theenhanced Make-Before-Break Handover request; and inserting an explicitenhanced Make-Before-Break Handover indicator in the RRC HandoverCommandmessage transferred to the source, in order to notify the UE.

It is furthermore provided herein a computer program product comprisinginstructions, which, when executed on at least one processor, cause theat least one processor to carry out the method above, as performed bythe source access node or the target access node, respectively. It isadditionally provided herein a computer-readable storage medium, havingstored thereon a computer program product comprising instructions which,when executed on at least one processor, cause the at least oneprocessor to carry out the method according to the method above, asperformed by the source access node or the target access node,respectively.

The object may be achieved by providing a source access node forhandling handover of a UE. The source access node is configured to sendto a target access node, an initial handover preparation message with afirst explicit indicator for the target access node to request anenhanced Make-Before-Break Handover. The source access node is furtherconfigured to receive an handover preparation response message from thetarget access node, with a second explicit indicator accepting orrejecting the requested enhanced Make-Before-Break Handover; and toselect a possible fallback mechanism, upon reception of the handoverpreparation response message from the target access node indicatingrejection or no support of enhanced Make-Before-Break Handover.

Compared to the prior art i.e. existing procedure for legacy handover asdescribed in background or release-14 Make-Before-Break handover,advantages of the solution according to embodiments described below isthat the source access node may:

-   -   for example, learn the target access node capability of eMBB        without prior capability exchange or configuration;    -   for example, signal to the target access node a desired fallback        mechanism to use if eMBB is not supported or is to be rejected        by the target node;    -   for example, be informed that the target access node does not        support eMBB and therefore not send DL packets to an already        detached UE;    -   for example, if the target access node does not support eMBB, be        informed that a legacy handover is prepared by the target access        node, and by that avoid starting a new Handover procedure.

The object may be achieved by providing a target access node forhandling handover of a UE, from a source access node to the targetaccess node. The target access node is configured to receive an initialhandover preparation message with a first explicit indicator from thesource access node requesting an enhanced Make-Before-Break Handover;and to respond to the initial handover preparation message sent by thesource access node, with a handover preparation response message with asecond explicit indicator accepting or rejecting the enhancedMake-Before-Break Handover request.

Compared to the prior art i.e. existing procedure for legacy handover orrelease-14 Make-Before-Break, advantages of the solution according toembodiments described below is that the target access node may:

-   -   for example, take an informed decision about accepting or        rejecting the eMBB request and start the required actions;    -   for example, signal to the source access node the acceptance of        the eMBB request;    -   for example, signal to the source access node the rejection of        the eMBB request, together with e.g. a chosen fallback        mechanism.

These actions according to embodiments herein as described above willresult in an optimized eMBB procedure which avoids unnecessarycapability configurations between nodes; avoids additional handoverdelay caused by failure or rejection of a handover request; and avoidsdiscrepancies in behaviour between UE, source and target access nodes.Therefore embodiments herein provide an improved method for handlinghandover of a UE.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples of embodiments herein are described in more detail withreference to attached drawings in which:

FIG. 1 illustrates a wireless communication network according to priorart;

FIG. 2 illustrates handover signalling in 5G/NR;

FIG. 3 illustrates Make-before-break signalling LTE;

FIG. 4 illustrates a proposed Enhanced MBB procedure to support 0 ms HOinterruption time in LTE Rel-16;

FIG. 5A illustrates a wireless communication network in whichembodiments herein may be implemented;

FIG. 5B is a flow chart illustrating a method performed in a sourceaccess node according to one embodiment herein;

FIG. 5C is a flow chart illustrating a method performed in a sourceaccess node according to one embodiment herein;

FIG. 6A is a flow chart illustrating a method performed in a targetaccess node according to another embodiment herein;

FIG. 6B is a flow chart illustrating a method performed in a targetaccess node according to another embodiment herein;

FIG. 7A is a schematic block diagram illustrating one embodiment of asource access node; and

FIG. 7B is a schematic block diagram illustrating one embodiment of atarget access node.

DETAILED DESCRIPTION

Intra-RAT (within same RAT), inter-RAT (between different RAT), NG-RAN,E-UTRAN and further disclaimers:

Most of the network and UE actions defined in embodiments herein aredescribed as being performed in NG-RAN or E-UTRAN. In all thesedifferent flavors, the source access node and the target access node forwhich enhanced Make-Before-Break (eMBB) may be prepared may each be:

An E-UTRAN node, i.e. an eNodeB; An NG-RAN node, i.e. a gNodeBsupporting NR; or a ng-eNodeB supporting LTE.

Then, the inter-node procedures described in embodiments herein may bebetween two eNodeBs, two gNodeBs, two ng-eNodeBs or any two RAN nodesfrom the same RAT or different RATs. Hence, they may be implemented inthe XnAP protocol, in the case of NG-RAN nodes connected to 5GC, or X2APprotocol or both.

In other words, the discussions regarding the inter-node procedures andmessages may be any of the following:

-   -   Inter-node intra-RAT intra-system, such as gNodeBs over Xn;    -   Inter-node intra-RAT intra-system, such as ng-eNodeBs over Xn;    -   Inter-node intra-RAT intra-system, such as eNodeBs over X2;    -   Inter-node inter-RAT intra-system, such as ng-eNodeBs and        gNodeBs over Xn;    -   Inter-node inter-RAT inter-system, such as E-UTRAN and NG-RAN,        i.e. gNodeBs/en-eNodeBs and eNodeBs over NG and S1.

In addition, the procedures also describe solutions involving messagesbetween RAN nodes and core network nodes over NG and S1 interface andbetween core network nodes from different systems, i.e. between EPC and5GC, over the N26 interface.

A wireless communication system according to embodiments herein isillustrated in FIG. 5A. The wireless communication system may compriseone or more radio access network (RAN), where a radio access network 100is shown with a user equipment (UE) 102, which communicates with one ormultiple access nodes 103-104, using radio connections 107-108. Theaccess nodes 103-104 are connected to a core network (CN) node 106. Theaccess nodes 103-104 are part of the radio access network 100. A sourceaccess node 103 and a target access node 104. Embodiments herein relateto eMBB handover of the UE 102 from the source access node 103 to thetarget access node 104.

The method actions performed by the source access node 103 for handlingHO of the UE 102 in the communication network 1 according to embodimentswill now be described with reference to a flowchart depicted in FIG. 5B.The actions do not have to be taken in the order stated below, but maybe taken in any suitable order. Actions performed in some embodimentsare marked with dashed boxes.

Action 501. The source access node 103 sends to the target access node104, the initial handover preparation message, e.g. a handover request,with a first explicit indicator for the target access node 104 torequest eMBB handover. The first explicit indication may be added as anadditional information in the initial handover preparation message sentfrom the source access node 103 to the target access node 104. The firstexplicit indicator may be included in an radio resource control (RRC)context signaled from the source access node 103 to the target accessnode 104. The first explicit indicator may be added in a handoverrequest message.

Action 502. The source access node 103 then receives a handoverpreparation response message from the target access node 104, with asecond explicit indicator accepting or rejecting the requested eMBBhandover.

Action 503. The source access node 103 may learn, from the handoverpreparation response message, a capability of the target access node 104related to enhanced Make-Before-Break handover. The capability of thetarget access node 104 may be learned based on successful responses orfailure responses of requested enhanced Make-Before-Break handovers.

Action 504. The source access node 103 may further notify the targetaccess node 104 of a desired fallback in case of failure or reject ofthe requested enhanced Make-Before-Break Handover. It should be notedthat the first explicit indicator for Enhanced Make-Before-Breakhandover and an indicator for the desired fallback mechanism may becombined in a single Information Element in the initial HandoverPreparation message in action 501.

Action 505. The source access node 103 may receive a notification fromthe target access node 104 of a selected possible fallback mechanism incase of rejection of the enhanced Make-Before-Break Handover request.

Action 506. The source access node 103 then selects a possible fallbackmechanism, upon reception of the handover preparation response messagefrom the target access node 104 indicating rejection or no support ofeMBB Handover. The source access node 103 may select the possiblefallback mechanism by taking the desired fallback into account and/orthe learned capability of the target access node 104. E.g. the sourceaccess node 103 may take the desired fallback into account, whichdesired fallback may be based on the learned capability of the targetaccess node 104. The possible and/or the desired fallback may compriseone or more of the following: a fallback to legacy handover; a fallbackto release-14 MBB handover; and a rejection of the handover request. Thesource access node 103 may select the possible fallback mechanism bytaking the notification from the target access node 104 of a selectedpossible fallback into account. Thus, embodiments herein may disclosethat in response to receiving the Handover Preparation response message,the source access node 103 may take a decision, based on the HandoverPreparation response message, about the possible fallback method uponreception of the target access node 104 rejecting eMBB.

Methods according to embodiments herein for enhanced handover will bedescribed in detail in the following.

I. Source Access node 103 Signalling in Initial Handover PreparationMessage:

According to an exemplified embodiment herein, a method performed in thesource access node 103 will be described with reference to FIG. 5C. Themethod comprises the following actions or steps, which actions may beperformed in any suitable order.

Action 511. The source access node 103 sends the initial HandoverPreparation message with the first explicit indicator, e.g. EnhancedMake-Before-Break Indicator, for the target access node 104 to requestan enhanced Make-Before-Break Handover.

In one implementation the first explicit indicator may be added as anadditional information in the initial Handover Preparation message sentfrom source to target.

In another implementation the first explicit indicator may be includedin the RRC Context signaled from source to target.

An example of a possible implementation of the first alternative above,taking XnAP (3GPP TS 38.423 v15.0.0) HANDOVER REQUEST message asbaseline is shown below indicated by the underlined text:

9.1.1.1 Handover Request

This message is sent by the source NG-RAN node to the target NG-RAN nodeto request the preparation of resources for a handover.Direction: source NG-RAN node→target NG-RAN node

IE type and IE/Group Name Presence Range reference Semantics descriptionMessage Type M 9.2.3.1 Source NG-RAN node UE M NG-RAN Allocated at thesource NG- XnAP ID reference node UE RAN node XnAP ID 9.2.3.16 Cause M9.2.3.2 Target Cell Global ID M 9.2.3.25 Includes either an E-UTRA CGIor an NR CGI GUAMI M 9.2.3.24 UE Context Information 1 >NG-C UEassociated M AMF UE Allocated at the AMF on the Signalling referenceNGAP ID source NG-C connection. 9.2.3.26 >Signalling TNL association MCP This IE indicates the AMF's IP address at source NG-C Transportaddress of the SCTP side Layer association used at the sourceInformation NG-C interface instance. 9.2.3.31 >UE Security CapabilitiesM 9.2.3.49 >AS Security Information M 9.2.3.50 >Index to RAT/Frequency O9.2.3.23 Selection Priority >UE Aggregate Maximum M 9.2.3.17 BitRate >PDU Session Resources 1 9.2.1.1 Similar to NG-C signalling, To BeSetup List containing UL tunnel information per PDU Session Resource;and in addition, the source side QoS flow ⇔ DRB mapping >RRC Context MOCTET Either includes the STRING HandoverPreparationInformation messageas defined in subclause 10.2.2. of TS 36.331 [14], if the target NG-RANnode is an ng-eNB, or the HandoverPreparationInformation message asdefined in subclause 11.2.2 of TS 38.331 [10], if the target NG-RAN nodeis a gNB. >Location Reporting O 9.2.3.47 Includes the necessaryInformation parameters for location reporting. >Mobility RestrictionList O 9.2.3.53 Trace Activation O 9.2.3.55 Masked IMEISV O 9.2.3.32 UEHistory Information M 9.2.3.64 UE Context Reference at O the S-NG-RANnode >Global NG-RAN Node ID M 9.2.2.3 >S-NG-RAN node UE M NG-RAN XnAP IDnode UE XnAP ID 9.2.3.16 Enhanced Make-Before- O ENUMERATED BreakIndicator (eMBB required, ... )

In one embodiment, the source access node 103 may notify the targetaccess node 104 of a desired fallback in case the target access node 104rejects the enhanced Make-Before-Break Handover (eMBB) request.

In one embodiment, the source access node 103 may take a decision aboutthe desired fallback mechanism if the target access node 104 rejects theenhanced Make-Before-Break request. This decision may be based on e.g.measurements, quality of service (QoS), UE capabilities, networkcapabilities, subscription, etc. An example of the possible fallbackmethods are listed below:

-   -   Fallback to legacy handover;    -   Fallback to release-14 MBB handover;    -   Reject the Handover Request.

In another embodiment, the source access node 103 may inform the targetaccess node 104 of the desired fallback mechanism, via e.g. additionalinformation in the initial Handover Preparation message.

In another embodiment, the indicator for Enhanced Make-Before-Break i.e.the first explicit indicator, and the indicator for desired fallbackmechanism may be combined in a single Information Element in the initialHandover Preparation message.

An example of a possible implementation of source access node 103informing the target access node 104, in an “IE EnhancedMake-Before-Break Information”, of desired fallback mechanism togetherwith the acceptance of the Enhanced Make-Before-Break request, takingXnAP (3GPP TS 38.423 v.15.0.0) HANDOVER REQUEST message as baseline, isshown below indicated by the underlined text:

9.1.1.1 Handover Request

This message is sent by the source NG-RAN node to the target NG-RAN nodeto request the preparation of resources for a handover.Direction: source NG-RAN node→target NG-RAN node.

IE type and IE/Group Name Presence Range reference Semantics descriptionMessage Type M 9.2.3.1 Source NG-RAN node UE M NG-RAN Allocated at thesource NG- XnAP ID reference node UE RAN node XnAP ID 9.2.3.16 Cause M9.2.3.2 Target Cell Global ID M 9.2.3.25 Includes either an E-UTRA CGIor an NR CGI GUAMI M 9.2.3.24 UE Context Information 1 >NG-C UEassociated M AMF UE Allocated at the AMF on the Signalling referenceNGAP ID source NG-C connection. 9.2.3.26 >Signalling TNL association MCP This IE indicates the AMF's IP address at source NG-C Transportaddress of the SCTP side Layer association used at the sourceInformation NG-C interface instance. 9.2.3.31 >UE Security CapabilitiesM 9.2.3.49 >AS Security Information M 9.2.3.50 >Index to RAT/Frequency O9.2.3.23 Selection Priority >UE Aggregate Maximum M 9.2.3.17 BitRate >PDU Session Resources 1 9.2.1.1 Similar to NG-C signalling, To BeSetup List containing UL tunnel information per PDU Session Resource;and in addition, the source side QoS flow ⇔ DRB mapping >RRC Context MOCTET Either includes the STRING HandoverPreparationInformation messageas defined in subclause 10.2.2. of TS 36.331 [14], if the target NG-RANnode is an ng-eNB, or the HandoverPreparationInformation message asdefined in subclause 11.2.2 of TS 38.331 [10], if the target NG-RAN nodeis a gNB. >Location Reporting O 9.2.3.47 Includes the necessaryInformation parameters for location reporting. >Mobility RestrictionList O 9.2.3.53 Trace Activation O 9.2.3.55 Masked IMEISV O 9.2.3.32 UEHistory Information M 9.2.3.64 UE Context Reference at O the S-NG-RANnode >Global NG-RAN Node ID M 9.2.2.3 >S-NG-RAN node UE M NG-RAN XnAP IDnode UE XnAP ID 9.2.3.16 Enhanced Make-Before- O Break Information >Enhanced Make-Before- M ENUMERATED Break Information (eMBB required,...) > Desired fallback method O ENUMERATED (legacy HO, rel14 MBB,reject, ...)

Action 512. The source access node 103 receives and processes a HandoverPreparation response message from the target access node 104, with anexplicit indicator, the second explicit indicator, accepting orrejecting the enhanced Make-Before-Break Handover request.

Action 513. In one embodiment, the source access node 103 may take thedecision about the possible fallback method as described in Action 506,after receiving the target access node response to the initial HandoverPreparation message. In that case the source access node 103 may make achoice between:

Accepting the Fallback Method Suggested by the Target Access Node 104;

-   -   Cancelling the handover procedure, e.g. using HANDOVER CANCEL        message, and starting a new Handover procedure, with the same        node, e.g. without eMBB indicator or with a different node.

The method actions performed by the target access node 104 handlinghandover of the UE from the source access node 103 to the target accessnode 104 according to embodiments herein will now be described withreference to a flowchart depicted in FIG. 6A. The actions do not have tobe taken in the order stated below, but may be taken in any suitableorder. Actions performed in some embodiments are marked with dashedboxes.

Action 601. The target access node 104 receives the initial handoverpreparation message with the first explicit indicator from the sourceaccess node 103 requesting an enhanced Make-Before-Break Handover.

Action 602. The target access node 104 may receive the notification fromthe source access node 103 of a desired fallback in case of failure orreject of the requested enhanced Make-Before-Break Handover.

Action 603. The target access node 104 may further select the possiblefallback mechanism in case of failure or rejection of the enhancedMake-Before-Break Handover. E.g. selection of fallback solution in thetarget access node 104 may be based on the desired fallback included inthe handover preparation message.

Action 604. The target access node 104 may then notify the source accessnode 103 of the selected possible fallback mechanism in case of failureor rejection of the enhanced Make-Before-Break Handover request.

Action 605. The target access node 104 responds to the initial handoverpreparation message sent by the source access node 103, with thehandover preparation response message with the second explicit indicatoraccepting or rejecting the enhanced Make-Before-Break Handover request.The target access node 104 may respond with a handover preparationresponse message to the source access node 103 with the second indicatorrejecting the enhanced Make Before Break Handover request and anindicator of selected possible fallback method. The target access node104 may respond by inserting an explicit enhanced Make-Before-BreakHandover indicator in the RRC HandoverCommand message transferred to thesource access node 103. The target access node 104 may select thepossible fallback mechanism by taking the received notification from thesource access node 103 of the desired fallback into account.

II. Handover Preparation Response from the Target Access Node 104.

According to one exemplified embodiment herein, a method performed inthe target access node 104 will be described with reference to FIG. 6B.The method comprises the following actions or steps, which actions maybe performed in any suitable order.

Action 611. The target access node 104 receives and processes theinitial Handover Preparation message with the explicit indicator, i.e.the first explicit indicator, from the source access node 103 requestingan enhanced Make-Before-Break Handover.

Action 612. The target access node 104 may then take a decision aboutthe enhanced Make-Before-Break request, e.g. accept, fallback or reject.This decision may be based on e.g. QoS, network capabilities, availableresources, configuration, etc. The target access node's decision may beas follows:

-   -   Enhanced Make-Before-Break handover accepted;    -   Fallback to legacy handover;    -   Fallback to rel-14 Make-Before-Break handover;    -   Handover rejected.

Action 613. If the target access node 104 accepts the eMBB handover, itsends Handover Preparation Response message to the source access node103 with the second explicit indicator accepting the enhanced MakeBefore Break Handover request.

The target access node 104 may inform the source access node 103 of itsdecision concerning the enhanced Make-Before-Break request via e.g.additional information in the Handover Preparation response message.

For successful or partial success, e.g. when fallback mechanism is used,an example of a possible implementation taking XnAP (3GPP TS 38.423v.15.0.0) HANDOVER REQUEST ACKNOWLEDGE message as baseline, adding an IE“Enhanced Make-Before-Break indicator” as indicated with underlinedtext:

9.1.1.2 Handover Request Acknowledge

This message is sent by the target NG-RAN node to inform the sourceNG-RAN node about the prepared resources at the target.Direction: target NG-RAN node→source NG-RAN node.

IE type and IE/Group Name Presence Range reference Semantics descriptionMessage Type M 9.2.3.1 Source NG-RAN node UE M NG-RAN node Allocated atthe source NG-RAN XnAP ID UE XnAP ID node 9.2.3.16 Target NG-RAN node UEM NG-RAN node Allocated at the target NG-RAN XnAP ID UE XnAP ID node9.2.3.16 PDU Session Resources M 9.2.1.2 Admitted List PDU SessionResources Not O 9.2.1.3 Admitted List Target NG-RAN node To M OCTETEither includes the Source NG-RAN node STRING HandoverCommand message asTransparent Container defined in subclause 10.2.2 of TS 36.331 [14], ifthe target NG-RAN node is an ng-eNB, or the HandoverCommand message asdefined in subclause 11.2.2 of TS 38.331 [10], if the target NG-RAN nodeis a gNB. UE Context Kept Indicator O 9.2.3.68 Criticality Diagnostics O9.2.3.3 Enhanced Make-Before- O ENUMERATED Break indicator (eMBBaccepted, fallback to legacy HO, fallback to rel14 MBB)

Action 614. If the target access node 104 rejects the eMBB handover, thetarget access node 104 may select a possible fallback method.

For handover failure, e.g. when the target access node 104 rejects theHO and no fallback method is used, an example of a possibleimplementation may be taking XnAP (3GPP TS 38.423 v.15.0.0) HANDOVERPREPARATION FAILURE message as baseline and using a new cause value eMBBrejected as indicated with underlined text:

9.1.1.3 Handover Preparation Failure

This message is sent by the target NG-RAN node to inform the sourceNG-RAN node that the Handover Preparation has failed.Direction: target NG-RAN node→source NG-RAN node.

IE/Group IE type and Semantics Name Presence Range reference descriptionMessage Type M 9.2.3.1 Source NG-RAN node UE M NG-RAN Allocated at theXnAP ID node UE source NG-RAN XnAP ID node 9.2.3.16 Cause M 9.2.3.2Criticality Diagnostics O 9.2.3.3

9.2.3.2 Cause

The purpose of the Cause IE is to indicate the reason for a particularevent for the XnAP protocol.

Semantics IE/Group Name Presence Range IE Type and Reference DescriptionCHOICE Cause M Group  >Radio  Network Layer   >>Radio M ENUMERATED  Network (   Layer Cause Cell not Available, Handover Desirable forRadio Reasons, Handover Target not Allowed, Invalid AMF Set ID, No RadioResources Available in Target Cell, Partial Handover, Reduce Load inServing Cell, Resource Optimisation Handover, Time Critical Handover,TXn_(RELOCoverall) Expiry, TXn_(RELOCprep) Expiry, Unknown GUAMI ID,Unknown Local NG-RAN node UE XnAP ID, Inconsistent Remote NG-RAN node UEXnAP ID, Encryption And/Or Integrity Protection Algorithms NotSupported, Protection Algorithms Not Supported, Multiple PDU Session IDInstances, Unknown PDU Session ID, Unknown QoS Flow ID, Multiple QoSFlow ID Instances, Switch Off Ongoing, Not supported 5QI value,TXn_(DCoverall) Expiry, TXn_(DCprep) Expiry, Action Desirable for RadioReasons, Reduce Load, Resource Optimisation, Time Critical action,Target not Allowed, No Radio Resources Available, Invalid QoScombination, Encryption Algorithms Not Supported, Procedure cancelled,RRM purpose, Improve User Bit Rate, User Inactivity, Radio ConnectionWith UE Lost, Failure in the Radio Interface Procedure, Bearer Optionnot Supported, UP integrity protection not possible, UP confidentialityprotection not possible, Resources not available for the slice(s), UEMaximum integrity protected data rate reason, CP Integrity ProtectionFailure, UP Integrity Protection Failure, Slice not supported by NG-RAN,MN Mobility, SN Mobility, Count reaches max value, Unknown Old NG-RANnode UE XnAP ID, PDCP Overload, DRB ID not available, eMBB rejected,Unspecified, . . . )  >Transport  Layer   >>Transport M ENUMERATED  Layer Cause (Transport Resource Unavailable, Unspecified, . . . ) >Protocol   >>Protocol M ENUMERATED   Cause (Transfer Syntax Error,Abstract Syntax Error (Reject), Abstract Syntax Error (Ignore andNotify), Message not Compatible with Receiver State, Semantic Error,Abstract Syntax Error (Falsely Constructed Message), Unspecified, . . .)  >Misc   >>Miscellaneous M ENUMERATED   Cause (Control ProcessingOverload, Hardware Failure, O&M Intervention, Not enough User PlaneProcessing Resources, Unspecified, . . . )

The meaning of the different cause values is specified in the followingtable. In general, “not supported” cause values indicate that therelated capability is missing. On the other hand, “not available” causevalues indicate that the related capability is present, but insufficientresources were available to perform the requested action.

Radio Network Layer cause Meaning Cell not Available The concerned cellis not available. Handover Desirable for Radio The reason for requestinghandover is radio related. Reasons Handover Target not Allowed Handoverto the indicated target cell is not allowed for the UE in question.Invalid AMF Set ID The target NG-RAN node doesn't belong to the same AMFSet of the source NG-RAN node, i.e. NG handovers should be attemptedinstead. No Radio Resources Available in The target cell doesn't havesufficient radio resources Target Cell available. Partial HandoverProvides a reason for the handover cancellation. The target NG-RAN nodedid not admit all PDU Sessions included in the HANDOVER REQUEST and thesource NG-RAN node estimated service continuity for the UE would bebetter by not proceeding with handover towards this particular targetNG- RAN node. Reduce Load in Serving Cell Load in serving cell needs tobe reduced. When applied to handover preparation, it indicates thehandover is triggered due to load balancing. Resource OptimisationHandover The reason for requesting handover is to improve the loaddistribution with the neighbour cells. Time Critical Handover Handoveris requested for time critical reason i.e. this cause value is reservedto represent all critical cases where the connection is likely to bedropped if handover is not performed. TXn_(RELOCoverall) Expiry Thereason for the action is expiry of timer TXn_(RELOCoverall).TXn_(RELOCprep) Expiry Handover Preparation procedure is cancelled whentimer TXn_(RELOCprep) expires. Unknown GUAMI ID The target NG-RAN nodebelongs to the same AMF Set of the source NG-RAN node and recognizes theAMF Set ID. However, the GUAMI value is unknown to the target NG-RANnode. Unknown Local NG-RAN node UE The action failed because thereceiving NG-RAN node does XnAP ID not recognise the local NG-RAN nodeUE XnAP ID. Inconsistent Remote NG-RAN The action failed because thereceiving NG-RAN node node UE XnAP ID considers that the received remoteNG-RAN node UE XnAP ID is inconsistent. Encryption And/Or Integrity Thetarget NG-RAN node is unable to support any of the Protection AlgorithmsNot encryption and/or integrity protection algorithms supported bySupported the UE. Multiple PDU Session ID The action failed becausemultiple instances of the same PDU Instances Session had been providedto the NG-RAN node. Unknown PDU Session ID The action failed because thePDU Session ID is unknown in the NG-RAN node. Unknown QoS Flow ID Theaction failed because the QoS Flow ID is unknown in the NG-RAN node.Multiple QoS Flow ID Instances The action failed because multipleinstances of the same QoS flow had been provided to the NG-RAN node.Switch Off Ongoing The reason for the action is an ongoing switch offi.e. the concerned cell will be switched off after offloading and not beavailable. It aides the receiving NG-RAN node in taking subsequentactions, e.g. selecting the target cell for subsequent handovers. Notsupported 5QI value The action failed because the requested 5QI is notsupported. TXnD_(Coverall) Expiry The reason for the action is expiry oftimer TXn_(DCoverall). TXn_(DCprep) Expiry The reason for the action isexpiry of timer TXn_(DCprep) Action Desirable for Radio The reason forrequesting the action is radio related. Reasons In the current versionof this specification applicable for Dual Connectivity only. Reduce LoadLoad in the cell(group) served by the requesting node needs to bereduced. In the current version of this specification applicable forDual Connectivity only. Resource Optimisation The reason for requestingthis action is to improve the load distribution with the neighbourcells. In the current version of this specification applicable for DualConnectivity only. Time Critical action The action is requested for timecritical reason i.e. this cause value is reserved to represent allcritical cases where radio resources are likely to be dropped if therequested action is not performed. In the current version of thisspecification applicable for Dual Connectivity only. Target not AllowedRequested action towards the indicated target cell is not allowed forthe UE in question. In the current version of this specificationapplicable for Dual Connectivity only. No Radio Resources Available Thecell(s) in the requested node don't have sufficient radio resourcesavailable. In the current version of this specification applicable forDual Connectivity only. Invalid QoS combination The action was failedbecause of invalid QoS combination. In the current version of thisspecification applicable for Dual Connectivity only. EncryptionAlgorithms Not The requested NG-RAN node is unable to support any of theSupported encryption algorithms supported by the UE. In the currentversion of this specification applicable for Dual Connectivity only.Procedure cancelled The sending node cancelled the procedure due toother urgent actions to be performed. In the current version of thisspecification applicable for Dual Connectivity only. RRM purpose Theprocedure is initiated due to node internal RRM purposes. In the currentversion of this specification applicable for Dual Connectivity only.Improve User Bit Rate The reason for requesting this action is toimprove the user bit rate. In the current version of this specificationapplicable for Dual Connectivity only. User Inactivity The action isrequested due to user inactivity on all PDU Sessions. The action may beperformed on several levels: - on UE Context level, if NG is requestedto be released in order to optimise the radio resources; or S-NG-RANnode didn't see activity on the PDU session recently. - on PDU SessionResource or DRB or QoS flow level, e.g. if Activity Notificationindicate lack of activity In the current version of this specificationapplicable for Dual Connectivity only. Radio Connection With UE Lost Theaction is requested due to losing the radio connection to the UE. In thecurrent version of this specification applicable for Dual Connectivityonly. Failure in the Radio Interface Radio interface procedure hasfailed. Procedure In the current version of this specificationapplicable for Dual Connectivity only. Bearer Option not Supported Therequested bearer option is not supported by the sending node. In thecurrent version of this specification applicable for Dual Connectivityonly. UP integrity protection not The PDU session cannot be acceptedaccording to the possible required user plane integrity protectionpolicy. UP confidentiality protection not The PDU session cannot beaccepted according to the possible required user plane confidentialityprotection policy. Resources not available for the The requestedresources are not available for the slice(s). slice(s) UE Maximumintegrity protected The request is not accepted in order to comply withthe data rate reason maximum data rate for integrity protectionsupported by the UE. CP Integrity Protection Failure The request is notaccepted due to failed control plane integrity protection. UP IntegrityProtection Failure The procedure is initiated because the SN (hostingnode) detected an Integrity Protection failure in the UL PDU coming fromthe MN. Slice not supported by NG-RAN The PDU session cannot be acceptedbecause the slice is not supported by the NG-RAN node. MN Mobility Theprocedure is initiated due to relocation of the M-NG-RAN node UEcontext. SN Mobility The procedure is initiated due to relocation of theS-NG-RAN node UE context. Count reaches max value, Indicates the PDCPCOUNT for UL or DL reached the max value and the bearer may be released.Unknown Old NG-RAN node UE The action failed because the Old NG-RAN nodeUE XnAP ID XnAP ID or the S-NG-RAN node UE XnAP ID is unknown. PDCPOverload The procedure is initiated due to PDCP resource limitation. DRBID not available The action failed because the M-NG-RAN node is not ableto provide additional DRB IDs to the S-NG-RAN node. eMBB rejected Theaction failed because the enhanced Make-Before- Break request has beenrejected. Unspecified Sent for radio network layer cause when none ofthe specified cause values applies.

Transport Layer cause Meaning Unspecified Sent when none of the abovecause values applies but still the cause is Transport Network Layerrelated.

NAS cause Meaning Unspecified Sent when none of the above cause valuesapplies but still the cause is NAS related.

Protocol cause Meaning Transfer Syntax The received message included atransfer Error syntax error. Abstract Syntax The received messageincluded an abstract Error (Reject) syntax error and the concerningcriticality indicated “reject”. Abstract Syntax The received messageincluded an abstract syntax Error error and the concerning criticalityindicated (Ignore And Notify) “ignore and notify”. Message Not Thereceived message was not compatible with Compatible the receiver state.With Receiver State Semantic Error The received message included asemantic error. Abstract Syntax The received message contained IEs or IEError groups in wrong order or with too many (Falsely occurrences.Constructed Message) Unspecified Sent when none of the above causevalues applies but still the cause is Protocol related.

Miscellaneous cause Meaning Control Processing Overload NG-RAN nodecontrol processing overload. Hardware Failure NG-RAN node hardwarefailure. Not enough User Plane NG-RAN node has insufficient user planeProcessing Resources processing resources available. O&M InterventionOperation and Maintenance intervention related to NG-RAN node equipment.Unspecified Sent when none of the above cause values applies and thecause is not related to any of the categories Radio Network Layer,Transport Network Layer or Protocol.

Action 615. In one embodiment, the target access node 104 sends HandoverPreparation Response message to the source access node 103 with thesecond explicit indicator rejecting the enhanced Make Before BreakHandover request and an indicator of selected possible fallback method.

In one embodiment, the target access node 104 not supporting eMBB maysend an Handover Request Failure with an existing cause value, e.g.Abstract Syntax Error (Reject).

In one embodiment, the source access node 103 receives and may processthe above Handover Preparation response message from the target accessnode 104, with the second explicit indicator accepting or rejecting theenhanced Make-Before-Break Handover request.

III. Target Access Node eMBB Capability Learning in the Source AccessNode 103.

Referring to action 503 in FIG. 5B, in one embodiment, dependent of theembodiments described above, the source access node 103 may learn aboutthe target access node eMBB capability according to the response fromthe target access node 104.

If the source access node 103 receives a successful response without anyadditional eMBB information, it may deduce that the target access node104 does not support eMBB.

If the source access node 103 receives a successful response withadditional eMBB information, e.g. eMBB accepted or desired fallback, itmay deduce that the target access node 104 supports eMBB.

If the source access node 103 receives a failure response withadditional eMBB information, e.g. cause value=eMBB not accepted, it maydeduce that the target access node 104 supports eMBB.

This information may be stored in the source access node 103 in order totake a decision concerning a subsequent handover to the same targetaccess node 104 for the same or a different UE.

IV. Enhanced Make-Before-Break Handover Indicator in the RRC HandoverCommand Being a Command Message Transferred to the Source Access Node103

In one embodiment, in case the target access node 104 accepts theenhanced Make-Before-Request request from the source access node 103,the target access node 104 may insert the second indicator exemplifiedas an enhanced Make-Before-Break indicator in the RRC HandoverCommandmessage corresponding to the RRCConnectionReconfiguration message withan MobilityControlInfo IE in LTE and an RRCReconfiguration message withan reconfigurationWithSync IE in NR, to signal the UE that it shouldperform an enhanced Make-Before-Break handover.

An ASN.1 example for LTE is given below, where anenhancedMakeBeforeBreak-r16 IE (underlined) is added in theMobilityControlInfo contained in the RRCConnectionReconfigurationmessage for LTE:

MobilityControlInfo ::= SEQUENCE { targetPhysCellId PhysCellId,carrierFreq CarrierFreqEUTRA OPTIONAL, -- Cond HO-toEUTRA2carrierBandwidth CarrierBandwidthEUTRA OPTIONAL, -- Cond HO-toEUTRAadditionalSpectrumEmission AdditionalSpectrumEmission OPTIONAL, -- CondHO-toEUTRA t304 ENUMERATED { ms50, ms100, ms150, ms200, ms500, ms1000,ms2000, ms10000-v1310}, newUE-Identity C-RNTI, radioResourceConfigCommonRadioResourceConfigCommon, rach-ConfigDedicated RACH-ConfigDedicatedOPTIONAL, -- Need OP ..., [[ carrierFreq-v9e0 CarrierFreqEUTRA-v9e0OPTIONAL -- Need ON ]], [[ drb-ContinueROHC-r11 ENUMERATED {true}OPTIONAL -- Cond HO ]], [[ mobilityControlInfoV2X-r14MobilityControlInfoV2X-r14 OPTIONAL, -- Need ONhandoverWithoutWT-Change-r14 ENUMERATED {keepLWA-Config, sendEndMarker}OPTIONAL, -- Cond HO makeBeforeBreak-r14 ENUMERATED {true} OPTIONAL, --Need OR enhancedMakeBeforeBreak-r16 ENUMERATED {true} OPTIONAL, -- NeedOR rach-Skip-r14 RACH-Skip-r14 OPTIONAL, -- Need ORsameSFN-Indication-r14 ENUMERATED {true} OPTIONAL -- Cond HO-SFNsynced]], [[ mib-RepetitionStatus-r14 BOOLEAN OPTIONAL, -- Need OR OPTIONAL --schedulingInfoSIB1-BR-r14 INTEGER (0..31) Cond HO-SFNsynced ]] }

An example for NR is given below, where an enhancedMakeBeforeBreak-r16IE (underlined) is added in the reconfigurationWithSync IE included inthe RRCReconfiguration message in NR:

ReconfigurationWithSync ::= SEQUENCE { spCellConfigCommonServingCellConfigCommon OPTIONAL, -- Need M newUE-Identity RNTI-Value,t304 ENUMERATED {ms50, ms100, ms150, ms200, ms500, ms1000, ms2000,ms10000}, rach-ConfigDedicated CHOICE { uplink  RACH-ConfigDedicated,supplementaryUplink  RACH-ConfigDedicated } OPTIONAL, -- Need NenhancedMakeBeforeBreak-r16 ENUMERATED {true} OPTIONAL, -- Need OR ...,[[ smtc SSB-MTC OPTIONAL  -- Need S ]] }V. Fallback to Release-14 MBB when Target Access Node 104 does notSupport eMBB.

In one embodiment the source access node 103 may combine the signalingmethod used for release-14 Make-Before-Break, i.e. addingmakeBeforeBreak-r14 indicator, in RRC HandoverPreparation message, andthe new indicator defined in action 501 i.e. the first explicitindicator. If the target access node 104 supports eMBB, and accepts theeMBB request, it will insert the RRC eMBB indicator in the RRCHandoverCommand message as defined in Action 605. If the target accessnode 104 supports eMBB, and rejects the eMBB request, it will insert theRRC release-14 MBB indicator in the RRC HandoverCommand message. If thetarget access node 104 does not support eMBB but supports release-14MBB, it will insert the release-14 RRC MBB indicator in the RRCHandoverCommand message.

VI. Possible Source Access Node 103 and Target Access Node 104 Actionsfor Enhanced Make-Before-Break Preparation.

The embodiment herein is defining the possible source and target accessnodes actions, related to network signaling, for the enhancedMake-Before-Break preparation. These actions are defined according tothe different possible scenarios. The different possible scenarios are acombination of the following criteria/events:

-   -   Target access node eMBB support and decision upon reception of        an eMBB request from the source access node 103:        -   I. Target access node 104 supports eMBB and accepts eMBB            request;        -   II. Target access node 104 supports eMBB and rejects eMBB            request;        -   III. Target access node 104 does not support eMBB.            Which node, i.e. source or target, takes the final decision            on the fallback method to be used in case the target access            node 104 rejects the eMBB request.    -   A. Fallback method is decided by target access node 104. Source        access node 103 can always cancel afterwards, if fallback method        is not suitable;    -   B. Fallback method is decided by the source access node 103        before the Handover Request;    -   C. Fallback method is decided by the source access node 103        after an Handover Preparation Failure received from the target        access node 104.        Fallback Method or other Source/Target Access Node Decisions:    -   1) Fallback to legacy Handover;    -   2) Fallback to release-14 Make-Before-Break;    -   3) Handover is rejected;    -   4) Handover is cancelled.        -   By combining all the possible choices, the following            behavior for source and target access nodes may be defined.

Target access node 104 supports eMBB and accepts eMBB request:

-   -   I. Target access node 104 adds the first explicit indicator e.g.        the eMBB indicator in the RRC HandoverCommand message and adds        an optional IE the second explicit indicator e.g. eMBB accepted,        to the Handover Request Acknowledge, i.e. the target access node        104 may explicitly signal that eMBB have been accepted so the        source access node 103 knows without having to check RRC        HandoverCommand message. It may be needed to differentiate an        “eMBB accepted” from an “eMBB not supported” event in some        cases. Source access node 103 can learn that target access node        104 supports eMBB.

Target access node 104 supports eMBB and rejects eMBB request:

-   -   II.A.1. Target access node 104 does not add the eMBB indicator        in the RRC HandoverCommand message and adds an optional IE e.g.        fallback to legacy HO, to the Handover Request Acknowledge. The        source access node 103 may learn that target access node 104        supports eMBB.    -   II.A.2. Target access node 104 adds the rel-14 MBB indicator in        the RRC HandoverCommand message and adds an optional IE e.g.        fallback to rel-14 MBB, to the Handover Request Acknowledge.        Source access node 103 can learn that target access node 104        supports eMBB. It is assumed that a source access node 103        supporting eMBB is also supporting rel-14 MBB.    -   II.A.3. Target access node 104 may send legacy the Handover        Preparation Failure message with a new cause value e.g. eMBB        rejected. Source access node 103 may then learn that target        access node 104 supports eMBB. Source access node 103 may try        another Handover Request to the same node without eMBB        indicator. Or try another target access node with or without        eMBB.    -   II.A.4. N/A    -   II.B.1 Target access node 104 does not add the eMBB indicator in        the RRC HandoverCommand message and adds an optional IE e.g.        fallback to legacy HO to the Handover Request Acknowledge.        Source access node 103 can learn that the target access node 104        supports eMBB.    -   II.B.2. Target access node 104 adds the rel-14 MBB indicator in        the RRC HandoverCommand message and adds an optional IE e.g.        fallback to rel-14 MBB, to the Handover Request Acknowledge.        Source access node 103 may learn that target supports eMBB.    -   II.B.3. Target access node 104 sends an Handover Preparation        Failure message with a new cause value e.g. eMBB rejected.        Source access node 103 may learn that target access node 104        supports eMBB. Source access node 13 can try another target        access node with or without eMBB.    -   II.B.4. Not needed. In that case source access node 103 should        use actions described in II.B.3.    -   II.C.1. Target access node 104 sends an Handover Preparation        Failure message with a new cause value e.g. eMBB rejected.        Source access node 103 may learn that target access node 104        supports eMBB. Source access node 103 will send a new Handover        Request without eMBB indicator.    -   II.C.2. Target access node 104 sends an Handover Preparation        Failure message with a new cause value e.g. eMBB rejected,.        Source access node 103 may learn that target access node 104        supports eMBB. Source access node 103 will send a new Handover        Request without rel-14 MBB indicator. Target access node 104        should be able to accept as rel-14 MBB does not need any        specific action from target access node 104.    -   II.C.3. Target access node 104 sends an Handover Preparation        Failure message with a new cause value e.g. eMBB rejected.        Source access node 103 may learn that target access node 104        supports eMBB. Source access node 103 may try another target        access node with or without eMBB.    -   II.C.4. N/A    -   Target access node 104 does not support eMBB.    -   III.A.1. Target access node 104 does not add the eMBB indicator        in the RRC HandoverCommand message and does not add an optional        IE to the Handover Request Acknowledge message. Source access        node 103 may learn that target access node 104 does not support        eMBB.    -   III.A.2. N/A unless the eMBB indicator in RRC is similar to the        rel-14 MBB indicator. In that case the target access node 104        adds the rel-14 MBB indicator in the HO Command and does not add        an optional IE to the HO Request Ack. Source access node 103 may        learn that target does not support eMBB. If this use-case needs        to be covered, signaling from source could combine 1 and 2 to        cover cases when target supports eMBB.    -   III.A.3. N/A    -   III.A.4. N/A    -   III.B. N/A    -   III.C.1. Similar to III.A.1. This is the default actions from a        target access node 104 not supporting eMBB.    -   III.C.2. Target access node 104 does not add the eMBB indicator        in the RRC HandoverCommand message and does not add an optional        IE to the Handover Request Acknowledge message. Source access        node 103 may learn that target access node 104 does not support        eMBB. Target access node 104 cancels the HO and sends a new        Handover Request with rel-14 MBB indicator.    -   III.C.3. N/A    -   III.C.4. Target access node 104 does not add the eMBB indicator        in the RRC HandoverCommand message eMBB. Source/target access        node cancels the HO and can try another target access node with        or without eMBB.

One alternative to the actions described above for a node not supportingeMBB is to send an Handover Request Failure with an existing cause valuee.g. Abstract Syntax Error (Reject).

To perform the method in the source access node 103, the source accessnode 103 may comprise modules as shown in FIG. 7A. The source accessnode 103 may comprise a receiving module 710, a transmitting module 720,a determining module 730, a processing module 740, a memory 750 etc. Thereceiving module 710, transmitting module 720, determining module 730and processing module 740 may be combined as one module, shown asprocessor 760.

The method according to embodiments herein may be implemented throughone or more processors, such as the processor 760 in the source accessnode 103 together with computer program code for performing thefunctions and actions of the embodiments herein. The program codementioned above may also be provided as a computer program product, forinstance in the form of a data carrier 780 carrying computer programcode 770, as shown in FIG. 7A, for performing the embodiments hereinwhen being loaded into the source access node 103. One such carrier maybe in the form of a CD ROM disc. It is however feasible with other datacarriers such as a memory stick. The computer program code mayfurthermore be provided as pure program code on a server or a cloud anddownloaded to the source access node 103.

The memory 750 in the source access node 103 may comprise one or morememory units and may be arranged to be used to store receivedinformation, measurements, data, configurations and applications toperform the method herein when being executed in the source access node103.

The source access node 103, the processor 760 or the transmitting module720 is configured to send to the target access node 104, the initialhandover preparation message with the first explicit indicator for thetarget access node 104 to request an enhanced Make-Before-BreakHandover.

The source access node 103, the processor 760 or the receiving module710 is configured to receive the handover preparation response messagefrom the target access node 104, with the second explicit indicatoraccepting or rejecting the requested enhanced Make-Before-BreakHandover.

The source access node 103, the processor 760 or the determining module730 is configured to select the possible fallback mechanism, uponreception of the handover preparation response message from the targetaccess node 104 indicating rejection or no support of enhancedMake-Before-Break Handover.

The source access node 103, the processor 760 or the processing module740 may be configured to notify the target access node 104 of thedesired fallback in case of failure or reject of the requested enhancedMake-Before-Break Handover.

The source access node 103, the processor 760 or the processing module740 may be configured to learn, from the handover preparation responsemessage, the capability of the target access node 104 related toenhanced Make-Before-Break handover. The capability of the target accessnode 104 may be learned based on successful responses or failureresponses of requested enhanced Make-Before-Break handovers. The sourceaccess node 103, the processor 760 or the determining module 730 may beconfigured to select the possible fallback mechanism taking the desiredfallback into account and/or the learned capability of the target accessnode 104.

The source access node 103, the processor 760 or the determining module730 may be configured to notify the target access node 104 of thedesired fallback, and wherein the first explicit indicator for EnhancedMake-Before-Break handover and an indicator for the desired fallbackmechanism is combined in a single Information Element in the initialHandover Preparation message.

The source access node 103, the processor 760 or the transmitting module720 may be configured to add the first explicit indication as anadditional information in the initial handover preparation message.

The first explicit indication may be included in a RRC context signalledfrom the source access node to the target access node. The firstexplicit indication may be added in a handover request message.

The possible and/or the desired fallback may comprise one or more of thefollowing: a fallback to legacy handover; a fallback to release-14 MBBhandover; and a rejection of the handover request.

The source access node 103, the processor 760 or the receiving module710 may be configured to receive the notification from the target accessnode 104 of a selected possible fallback mechanism in case of rejectionof the enhanced Make-Before-Break Handover request.

The source access node 103, the processor 760 or the determining module730 may be configured to select the possible fallback mechanism bytaking the notification into account.

To perform the method in the target access node 104, the target accessnode 104 may comprise modules as shown in FIG. 7B. The target accessnode 104 may comprise a receiving module 711, a transmitting module 721,a determining module 731, a processing module 741, a memory 751 etc. Thereceiving module 711, transmitting module 721, determining module 731and processing module 741 may be combined as one module, shown asprocessor 761.

The target access node 104, the processor 761 and/or the receivingmodule 711 is configured to receive the initial handover preparationmessage with the first explicit indicator from the source access node103 requesting the enhanced Make-Before-Break Handover.

The target access node 104, the processor 761 and/or the transmittingmodule 721 is configured to respond to the initial handover preparationmessage sent by the source access node 103, with the handoverpreparation response message with the second explicit indicatoraccepting or rejecting the enhanced Make-Before-Break Handover request.

The target access node 104, the processor 761 and/or the determiningmodule 731 may be configured to select the possible fallback mechanismin case of failure or rejection of the enhanced Make-Before-BreakHandover.

The target access node 104, the processor 761 and/or the transmittingmodule 721 may be configured to notify the source access node 103 of theselected possible fallback mechanism in case of failure or rejection ofthe enhanced Make-Before-Break Handover request.

The target access node 104, the processor 761 and/or the transmittingmodule 721 may be configured to respond with the handover preparationresponse message to the source access node 103 with the second indicatorrejecting the enhanced Make Before Break Handover request and theindicator of selected possible fallback method.

The target access node 104, the processor 761 and/or the transmittingmodule 721 may be configured to respond by inserting the explicitenhanced Make-Before-Break Handover indicator in the RRC HandoverCommandmessage transferred to the source access node 103.

The target access node 104, the processor 761 and/or the receivingmodule 711 may be configured to receive the notification from the sourceaccess node 103 of the desired fallback in case of failure or reject ofthe requested enhanced Make-Before-Break Handover. The target accessnode 104, the processor 761 and/or the determining module 731 may beconfigured to select the possible fallback mechanism taking the receivednotification into account.

The method according to embodiments herein may be implemented throughone or more processors, such as the processor 761 in the target accessnode 104 together with computer program code for performing thefunctions and actions of the embodiments herein. The program codementioned above may also be provided as a computer program product, forinstance in the form of a data carrier 781 carrying computer programcode 771, as shown in FIG. 7B, for performing the embodiments hereinwhen being loaded into the target access node 104. One such carrier maybe in the form of a CD ROM disc. It is however feasible with other datacarriers such as a memory stick. The computer program code mayfurthermore be provided as pure program code on a server or a cloud anddownloaded to the target access node 104.

The memory 751 in the target access node 104 may comprise one or morememory units and may be arranged to be used to store receivedinformation, measurements, data, configurations and applications toperform the method herein when being executed in the target access node104.

Below are some embodiments described.

Embodiment 1: A method in a source access node to perform handover of aUE to a target access node comprising:

-   -   sending an initial Handover Preparation message with an        indicator for the target access node to request an enhanced        Make-Before-Break Handover;    -   notifying the target access node of the desired fallback in case        of rejection of the enhanced Make-Before-Break Handover request;    -   receiving a Handover Preparation response message from the        target access node, with an indicator accepting or rejecting the        enhanced Make-Before-Break Handover request;    -   in response to receiving the Handover Preparation response        message, taking a decision about the possible fallback method        upon reception of the target access node rejecting enhanced        Make-Before-Break Handover.

Embodiment 2: according to the Embodiment 1, wherein the source accessnode learns the target access node enhanced Make-Before-Break capabilityfrom the target response message to the enhanced Make-Before-BreakHandover request.

Group B Embodiments

Embodiment 3: A method in a target access node to perform handover of aUE from a source access node comprising:

-   -   receiving an initial Handover Preparation message with an        indicator from the source access node requesting an enhanced        Make-Before-Break Handover;    -   responding to the initial Handover Preparation message sent by        the source access node, with an indicator accepting or rejecting        the enhanced Make-Before-Break Handover request;    -   selecting a possible fallback method in case of rejection of the        enhanced Make-Before-Break Handover;    -   notifying the source access node of the selected fallback method        in case of rejection of the enhanced Make-Before-Break Handover        request;    -   inserting an explicit enhanced Make-Before-Break Handover        indicator in the RRC HandoverCommand message transferred to the        source access node, in order to notify the UE.

In case the texts in FIGS. 2-4 are too small and blurry to read,references are given below:

-   -   FIG. 2 : From 3GPP TS 38.300 v15.2.0, FIG. 9.2.3.2.1-1    -   FIG. 3 : From 3GPP TS 36.300 v14.8.0, FIG. 10.1.2.1.1-1    -   FIG. 4 : From R2-1817396, Enhancements to Make-Before-Break,        Ericsson, 3GPP TSG-RAN WG2 #104, Spokane, USA, 12th-16th Nov.        2018.        At least some of the following abbreviations may be used in this        disclosure. If there is an inconsistency between abbreviations,        preference should be given to how it is used above. If listed        multiple times below, the first listing should be preferred over        any subsequent listing(s).

Abbreviation Explanation 5GS 5G System 5GC 5G Core network AMF Accessand Mobility Management Function CHO Conditional Handover C-RNTI CellRNTI DL Downlink eNB Evolved Node B eMBB Enhanced Make-before-breakE-UTRAN Evolved Universal Terrestrial Access Network EPC Evolved PacketCore network gNB 5G Node B HO Handover IE Information Element LTELong-term Evolution MBB Make-before-break NCC Next Hop Chaining CounterNG-RAN Next Generation Radio Access Network NR New Radio PDCP PacketData Convergence Protocol RA Random Access RAR Random Access ResponseRAT Radio Access Technology RNTI Radio Network Temporary Identifier RRCRadio Resource Control Rx Receive SDU Service Data Unit SN SequenceNumber Tx Transmit UE User Equipment UL Uplink UPF User Plane Function

1. A method performed by a source access node relating to handover of auser equipment, UE, the method comprising: sending to a target accessnode, an initial handover preparation message for the target access nodeto request an enhanced Make-Before-Break Handover; receiving a handoverpreparation response message from the target access node accepting orrejecting the requested enhanced Make-Before-Break Handover; andselecting a possible fallback mechanism, upon reception of the handoverpreparation response message from the target access node.
 2. The methodaccording to claim 1, further comprising: notifying the target accessnode of a desired fallback in case of failure or reject of the requestedenhanced Make-Before-Break Handover.
 3. The method according to claim 1,further comprising: learning, from the handover preparation responsemessage, a capability of the target access node related to enhancedMake-Before-Break handover.
 4. The method according to claim 3, whereinthe capability of the target access node is learned based on successfulresponses or failure responses of requested enhanced Make-Before-Breakhandovers.
 5. The method according to claim 2, wherein selecting thepossible fallback mechanism takes into account at least one of thedesired fallback and the learned capability of the target access node.6. The method according to claim 2, wherein the source access nodenotifies the target access node of the desired fallback, and wherein afirst explicit indicator for Enhanced Make-Before-Break handover and anindicator for the desired fallback mechanism are combined in a singleInformation Element in the initial Handover Preparation message.
 7. Themethod according to claim 6, wherein the first explicit indication isadded as an additional information in the initial handover preparationmessage send from source to target.
 8. The method according to claim 1,wherein the possible fallback mechanism comprises one or more of thefollowing: a fallback to legacy handover; a fallback to release-14Make-Before-Break handover; and a rejection of the handover request. 9.The method according to claim 1, further comprising: receiving anotification from the target access node of a selected possible fallbackmechanism in case of rejection of the enhanced Make-Before-BreakHandover request.
 10. A method performed by a target access noderelating to handover of a user equipment, UE, from a source access nodeto the target access node, the method comprising: receiving an initialhandover preparation message with a first explicit indicator from thesource access node requesting an enhanced Make-Before-Break Handover;and responding to the initial handover preparation message sent by thesource access node, with a handover preparation response messageaccepting or rejecting the enhanced Make-Before-Break Handover request.11. The method according to claim 10, further comprising: selecting apossible fallback mechanism in case of one of failure and rejection ofthe enhanced Make-Before-Break Handover; and notifying the source accessnode of the selected possible fallback mechanism in case of one offailure and rejection of the enhanced Make-Before-Break Handoverrequest.
 12. The method according to claim 11, responding with ahandover preparation response message to the source access noderejecting the enhanced Make Before Break Handover request and anindicator of selected possible fallback method.
 13. The method accordingto claim 10, wherein responding comprises inserting an explicit enhancedMake-Before-Break Handover indicator in the RRC HandoverCommand messagetransferred to the source access node.
 14. The method according to claim10, further comprising: receiving a notification from the source accessnode of a desired fallback in case of one of failure and rejection ofthe requested enhanced Make-Before-Break Handover.
 15. A source accessnode for handling handover of a user equipment, UE, the source accessnode being configured to: send to a target access node, an initialhandover preparation message for the target access node to request anenhanced Make-Before-Break Handover; receive a handover preparationresponse message from the target access node, with a second explicitindicator accepting or rejecting the requested enhancedMake-Before-Break Handover; select a possible fallback mechanism, uponreception of the handover preparation response message from the targetaccess node.
 16. The source access node according to claim 15, whereinthe source access node is further configured to: notify the targetaccess node of a desired fallback in case of one of failure andrejection of the requested enhanced Make-Before-Break Handover.
 17. Thesource access node according to claim 15, wherein the source access nodeis further configured to: learn, from the handover preparation responsemessage, a capability of the target access node related to enhancedMake-Before-Break handover.
 18. The source access node according toclaim 17, wherein the capability of the target access node is learnedbased on successful responses or failure responses of requested enhancedMake-Before-Break handovers.
 19. The source access node according toclaim 16, wherein the source access node is configured to select thepossible fallback mechanism taking into account at least one of thedesired fallback and the learned capability of the target access node.20. The source access node according to claim 16, wherein the sourceaccess node is configured to notify the target access node of thedesired fallback, and wherein the first explicit indicator for EnhancedMake-Before-Break handover and an indicator for the desired fallbackmechanism is combined in a single Information Element in the initialHandover Preparation message.